1. Field of the Invention
The present invention relates to transacting commerce over a network and, more particularly, to a method and apparatus for processing information related to such commercial transactions.
2. Description of the Related Art
Historically, information regarding commercially available products has been disseminated using various types of well-known media, including print, radio, television, and the like. With the advent of the Internet, a wide array of product information has become even more accessible to the average person. Entities providing such product information have been assisted in their endeavor by networking and client/server technology that has become available in approximately the last ten to fifteen years. Such technology typically allows a number of users employing client terminals to communicate with a remote server computer in order to transfer information therebetween. This information may include text, data in any one of a number of formats, graphical information, streaming audio and video, and other such information. To facilitate such transfers, client terminals can employ a “web” browser that provides access to a server via a graphical user interface (GUI). The server responds to requests from the client by providing information in the form of a “web page.” One popular collection of servers uses Hypertext Transfer Protocol (HTTP) to provide information. This network of servers and web pages is commonly known as the “World Wide Web” (WWW). A collection of related web pages is often referred to as a “website” or more simply a “site.” Information in the WWW is typically presented as web pages which contain text along with standardized formatting and control symbols such as those present in mark-up languages such as Hypertext Mark-up Language (HTML). HTML provides basic hypertext document formatting and allows a server to specify “links” to other servers and files. Use of an HTML-compliant browser involves specification of a link via a Uniform Resource Locator (URL). Upon such specification, the user's client terminal makes a TCP/IP request to the server identified in the link and receives an HTML file that is interpreted by the browser so that an electronic HTML document made up of one or more web pages may be displayed on the client's terminal.
Unfortunately, however, the use of the functionality provided by technologies that allow the selection and purchase of products (e.g., e-commerce websites) is less than ideal. Client-side performance is a significant factor in such a network environment, especially in an e-commerce context, and factors that degrade website performance likewise degrade the purchasing experience. Fundamentally, a website that is slow (and therefore aggravating to use) can result in lost sales. Thus, factors that degrade client-side performance should be avoided if the user's buying experience is to be a pleasant one. An example of such a factor is the time involved in accessing a product information database, especially where the database access is performed over a network of some sort (e.g., a storage area network (SAN)). Such effects can depend on several factors, with certain of these factors being quite intuitive in nature.
In the case where a customer desires pricing information for various configurations of a selected product, pricing of a base configuration of a product or a product with a pre-set, “standard” feature set is relatively straightforward. However, as the customer adds features to and removes features from the selected product, the product's final price may change according to not only the features added or removed, but also according to any package pricing, discounts, variations in taxes and/or shipping charges, and other such adjustments. Moreover, the selection of one feature may change the price of another selected feature, require other upgrades, obviate the need for certain features, and/or may change the classification of the current package altogether. There may also be differences in pricing for a given feature based on the customer (e.g., the customer's status, location, contractual agreement or the like), product-specific discounting schemes, and other such criteria. Further, other factors such as shipping may change relative to the configuration, number of items, and so on.
For example, in an e-commerce scenario, if the price of a single product configuration is desired, various factors (e.g., user identity, geographical location, promotions, volume and the like) can be taken into account when pricing the product (or service) for purchase (e.g., via an e-commerce website). This pricing request results in a database access that gathers the requisite pricing information. An example of such a pricing system (or pricing engine) is described in U.S. Pat. No. 5,878,400, issued Mar. 2, 1999, by Carter and entitled “Method and Apparatus for Pricing Products in Multi-Level Product and Organizational Groups.” Thus, pricing on a component-by-component level is generally available.
In the situation where a product is available in a number of configurations (each of which represent a given set of features), however, each product configuration will typically include different combinations of the available features. Each such configuration needs to be priced accordingly. This requires multiple accesses, typically over a network, to retrieve the necessary data and generate the desired pricing information. The problem is compounded when the pricing information for a given feature (or other cost) depends upon the features selected in a given configuration. In an e-commerce system such as that described previously, this is especially problematic if the user desires to compare pricing between a number of configurations simultaneously. This is because the user is forced to wait for all the database accesses to complete before a complete comparison can be made. Thus, delays are particularly evident in the situation where a user desires pricing information for a number of product configurations simultaneously.
For example, as noted, a prospective purchaser may desire to configure and price an automobile. The prospective purchaser does not want to wait until they have specified all the possible options in order to view a price. In fact, the prospective purchaser may desire to view both a running total price, as well as the incremental price of each item that the prospective purchaser is currently considering. For example, the prospective purchaser may have already configured a base vehicle, but is provided the option of selecting a “CD Player” or a “High-End Stereo System.” The decision on which to purchase is typically based on, among other criteria, on the change in price caused by each option. One option is to display the $500 price of the CD Player and the $750 price of the High-End System. However, the currently configured base vehicle already has the standard stereo (costing $200). The manufacturer would prefer that the prospective purchaser realize that the CD Player only costs $300 additionally and the High-End System only costs $550 additionally. This is effectively an upsell opportunity.
Similar to seeing the choice for radio options, a potential purchaser might also see the option of purchasing leather seats. Though the leather seats only cost $1500, the leather seats are simply not offered on the base vehicle and are instead offered only on the Luxury model. The Luxury package costs $2000, bringing the cost of the current configuration to $3500. To make the example more complete, consider that the currently priced base vehicle costs $19,000, but a purchaser receives a $1000 rebate check if the vehicle costs $20,000 or more. Even though the Luxury package and leather seats add $3500 to the current price, in fact a $1,000 rebate is given (resulting in a net difference of only $2500).
In light of the variations presented in the foregoing example, and the myriad other possible variations and combinations thereof, incremental differences in price (i.e., the difference between the price of the currently configured vehicle and another configuration) need to be calculated, and the price of the vehicle configured with the various options presented. The example demonstrates that this requires some configuration integration (i.e., to know the base radio needs to be removed, or the Luxury package needs to be added). A configuration with the leather seats, combined with the rebate, illustrates that the old product price cannot simply be manipulated by adding/subtracting the prices of the individual options. To get the true price, the pricing engine must calculate the product's total price with each desired set of options. As will be apparent to one of skill in the art, when such operations must be performed for every option presented to a prospective purchaser, tens or even hundreds of such operations must be performed every time the information is redisplayed, which should occur every time the potential purchaser adds or removes an option from the given configuration.
One method of addressing this need is to call a pricing engine (through the pricing service or using the methods directly), and so create a collection of items and price all the items together in the context of a quote. To perform pricing operations using such an approach, a separate quote with all of the base items must be individually created, with the quote including the options being added to the base configuration (e.g., a new radio, or leather seats and the luxury package together) and excluding the options to be removed (e.g., the stock radio). Each quote is priced separately with no benefit from having already retrieved the appropriate adjustments from the database or the previously-calculated base price. This creates a multitude of database accesses, with the attendant problems discussed earlier.
Another alternative is to simply price all possible (or allowable) combinations of features, and then save the pricing and feature information thus generated in a database accessible by the web server presenting the information to the customer. While conceptually simple, this solution suffers from several infirmities. Such a database would be quite large by a relative measure, increasing retrieval time, as well as the cost of maintaining such information. Also, the database would need to be accessed each time a new quote was required, entailing the aforementioned increase in retrieval time for each such quote. Each access, in turn, would necessitate the regeneration of the web page to display the results of each such access, further delaying the display of pricing information. Also, because of the large number of potential configurations, generation of this pricing data is often impractical.
Thus, the list price of a given feature may not reflect the price to actually be paid by the customer for a variety of reasons, and so determination of a product's final price can be a complex, and time-consuming, exercise. By contrast, when investigating the costs associated with various combinations of features, and when employing web-based technology in general, providing the desired pricing information quickly and accurately improves a customer's buying experience, as well as increasing the likelihood that the customer will actually make a purchase. Moreover, the earlier in the navigation of the e-commerce website this information can be provided to the prospective purchaser, the more likely the prospective purchaser is to complete the purchase.
Furthermore, prospective purchasers are also more likely to make a purchase in the scenario where the prospective purchaser sees a given combination of features (products, services or the like) as costing only an incremental amount over a “base” (or given) configuration. By making the increment the focus of the prospective purchaser's attention, emphasis on the total outlay is minimized in the user's mind. This can encompass any costs associated with a given purchase.